Hmm, shouldn't you go a bit deeper and catch the drain event emitted by the HTTP response? In order to be sure that the packet has been written to the kernel buffer and can safely be released.

References:

• https://nodejs.org/api/http.html#responsewritechunk-encoding-callback
• https://nodejs.org/api/http.html#event-drain

Related: #5353

Hmm, shouldn't you go a bit deeper and catch the drain event emitted by the HTTP response? In order to be sure that the packet has been written to the kernel buffer and can safely be released.

References:

• https://nodejs.org/api/http.html#responsewritechunk-encoding-callback
• https://nodejs.org/api/http.html#event-drain

Related: #5353

For Websockets, the ws library is handling that I think and it won't callback until its finished writing out. Do you see something different?

You are possibly right about long-polling though; I can defer our drain until the HTTP drain. I just pushed out that change. Though does long-polling even support buffers? I was under the impression it was base64-ing them.

I am not seeing a mechanism for uWebSockets to tell us when they have actually written out the buffer.

Hi, just wanted to check in on this PR @darrachequesne; I can update it to eliminate the conflicts but I don't want to keep doing it if it won't merge soon.

@darrachequesne Can I do anything to help get more engagement on this PR? Thanks!